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Who am I 



• Security Researcher at Norman 

• Malware Detection Team (MDT) 

• Interests 

• Vulnerability research 

• Operating system internals 

• Past Work 

• Kernel Pool Exploitation on Windows 7 

• Mitigating NULL Pointer Exploitation on Windows 
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About this Talk 



• Several vulnerability classes related to 
windows hooks and user-mode callbacks 

• Null pointer dereferences 

• Use-after-frees 

• Resulted in 44 patched privilege escalation 
vulnerabilities in MSll-034 and MSll-054 

• Several unannounced vulnerabilities were also 
addressed as part of the variant discovery process 

• Requires understanding of several mechanisms 
specific to NT and win32k 
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Introduction 

Win32k and User-Mode Callbacks 
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Win32k 



• The Windows GUI subsystem was traditionally 
implemented in user-mode 

• Used a client-server process model 

• In NT 4.0, a large part of the server component 
(in CSRSS) was moved to kernel-mode 

• introduced Win32k.sys 

• Today, Win32k manages both the Window 
Manager (USER) and the Graphics Device 
Interface (GDI) 
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User-Mode Callbacks 



• Allows win32k to make calls back into user- 
mode and operate on user-mode data 

• Invoke application defined hooks 

• Provide event notifications 

• Read and set properties in user-mode structures 

• Implemented in the NT executive 

• ntlKeUserModeCallback 

• Works like a reverse system call 



NORMAN 



Win32k vs. User-Mode Callbacks 



• Win32k uses a global locking design in creating 
a thread-safe environment 

• Presumably remnants of the old subsystem design 

• Callbacks 'Interrupt'" kernel execution and 
allow win32k structures and object properties 
to be modified 

• Insufficient checks or validation may result in 
numerous vulnerabilities 

• Use-after-frees 

• NULL pointer dereferences 

• ++ 
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Previous Work 



• Mxatone - Analyzing local privilege escalations in 
win32k (Uninformed vol.10) 

• Insufficient validation of data returned from user-mode 
callbacks 

• Win32k Window Creation Vulnerabilities 

• CVE-2010-0484 (MSlO-032) 

• Window parent not revalidated after callbacks 

• CVE-2010-1897 (MSlO-048) 

• Pseudo handle provided in callback not sufficiently validated 

• Stefan Esser - State of the Art Post Exploitation in 
Hardened PHP Environments (BlackHat USA 2009) 

• Interruption vulnerabilities 
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Goals 



• Show how user-mode callbacks without very 
stringent checks may introduce several subtle 
vulnerabilities 

• Show how such vulnerabilities may be 
exploited using pool and kernel heap 
manipulation 

• Propose a method to generically mitigate 
exploitability of NULL pointer dereference 
vulnerabilities 
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Win32k 



Architecture and Design 



Windows NT 3.51 



• Modified microl<ernel design 

• File systems, network protocols, IPC, and drivers are 
implemented in kernel mode 

• Followed a more pure microkernel approach in 
its implementation of the GUI subsystem 

• Window Manager and GDI implemented in the 
Client-Server Runtime Subsystem (CSRSS) 

• Optimized for performance 

• Shared memory design 

• Paired threads between client and server (FastLPC) 
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Windows NT 3.51 Win32 Subsystem 



Client Server Runtime 
Subsystem (CSRSS) 



Text windowing 
support 



Console 



Handles input and 
manages screen I/O 



Window 
Manager 



^ Drawing library for 
graphics output devices 



Graphics Device Interface 



Win32 
Subsystem 



Supports all components 
in the subsystem 



Operating System 
Functions 



User 



I 

I 



Graphics Device 
Drivers 



Hardware dependent 
graphics drivers 



Kernel 



Executive Services 



Microkernel 



HAL 
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Drawbacks of the NT 3.51 Design 



• Graphics and windowing subsystem have a very 
high rate of interaction with hardware 

• Video drivers, mouse, keyboard, etc. 

• Client-server interaction involves excessive 
thread and context switching 

• Greatly affects graphics rendering performance 

• High memory requirements 

• Uses 64K shared memory buffer to accumulate and 
pass parameters between the client and server 
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Windows NT 4.0 



• Moved the Window Manager, GDI and graphics 
device drivers to l<ernel-mode 

• Introduced win32k.sys 

• Eliminated the need for shared buffers and 
paired threads 

• Results in fewer thread and context switches 

• Reduces memory requirements 

• Some old performance tricks were still 
maintained 

• E.g. caching of management structures in the user 
mode portion of the client's address space 
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Win32k.sys in Windows NT 4.0 



User 
Kernel 




CSR 

Subsystem 



Window 
Manager 



Graphics 
Device Interface 



Graphics 
Device Drivers 



Microkernel 



Win32k.sys 



HAL 



NORMAN 



Win32k 



• Kernel component of the Win32 subsystem 

• Implements the kemel side of 

• Window Manager (USER) 

• Graphics Device Interface (GDI) 

• Provides thunks to DirectX interfaces 

• Has it's own system call table 

• More than 800 entries on Windows 7 

• win32k!W32pServiceTable 
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Window Manager (USER) 



• Several responsibilities 

• Controls window displays 

• Manages screen output 

• Collects input from keyboard, mouse, etc. 

• Calls application-defined hooks 

• Passes user messages to applications 

• Manages user objects 

• The component this talk will focus on 



Graphics Device Interface (GDI) 



• Manages the graphics output and rendering 

• Library of functions for graphics output devices 

• Includes functions for line, text, and figure drawing 
and for graphics manipulation 

• Manages GDI objects such as brushes, pens, DCs, 
paths, regions, etc. 

• Provides APIs for video/print drivers 

• Slow compared to Direct2D/DirectWrite 

• Will probably be replaced at some point 
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DirectX Thunks 



• Entry point thunks for DirectX support 

• NtGdiDd*orNtGdiDDI* 

• Calls corresponding functions in the DirectX 
driver 

• dxg.sys (XDDM) or dxgkrnl.sys (WDDM) depending on 
the display driver model used 

• Display drivers hook DXG interfaces to 
hardware accelerate or punt back to GDI 
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Window Manager 

User Objects and Thread Safety 
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User Objects 



• All user handles for entities such as windows and 
cursors are backed by their own object 

• Allocated in win32k!HMAIIocateObject 

• Each object type is defined by a unique structure 

• win32k!tagWND 

• win32k!tagCURSOR 

• User objects are indexed into a dedicated handle 
table maintained by win32k 

• Handle values are translated into object pointers 
using the handle manager validation APIs 

• win32k!HMValidateHandle(..) 
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User Object Header 



• Every user object starts with a HEAD structure 

• kd> dt win32k!_HEAD 

• +0x000 h :Ptr32Void // handle value 

• +0x004 cLockObj : Uint4B // lock count 

• The lock count tracks object use 

• An object is freed when the lock count reaches zero 

• Additional fields are defined if the object is owned 
by a thread or process, or associated with a 
desktop 

• win32k!_THRDESKHEAD 

• win32k! PROCDESKHEAD 
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User Handle Table 



• All user objects are indexed into a per-session 
handle table 

• Initialized in win32k!Win32Userlnitialize 

• Pointer to the user handle table is stored in the 
win32k!tagSHAREDINFO structure 

• user32!gSharedlnfo (Win 7) or win32k!gSharedlnfo 

• kd> dt win32k!tagSHAREDINFO 

• +0x000 psi : Ptr32tagSERVERINFO 

• +0x004 aheList : Ptr32 _HANDLEENTRY 

• +0x008 HeEntrySize : Uint4B 

• +OxOOc pDisplnfo : Ptr32 tagDISPLAYINFO 

• +0x010 ulSharedDelta : Uint4B 
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User Handle Table Entries 



• Each entry in the user handle table is represented 
by a HANDLEENTRY structure 

• kd> dt win32kLHANDLEENTRY 

• +0x000 phead :Ptr32_HEAD 

• +0x004 pOwner : Ptr32 Void 

• +0x008 bType : Uchar 

• +0x009 bFlags : Uchar 

• +OxOOawUniq : Uint2B 

• Holds pointers to the object, its owner, type, flags, 
and a unique seed for the handle values 

• handle = handle_table_index | (wUniq « 0x10) 

• wUniq is incremented on object free 
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User Handle Table Entries 



object 


owner 


bType 


bFlags 


wUniq 


0 


0 


0 


0 


0 


ff9dld28 


0 


c 


0 




ffbbd498 ffb09678 


1 


40 




ffb658f0 


ffbbc958 


3 


0 




ff650618 


ffb09678 


1 


0 




ffb64918 


ffbbc958 


3 


0 





Pointer to object 
in l<ernel memory 




Pointer to owner 
(THREADINFO or 
PROCESSINFO) 




Object type (e.g 
window, cursor, 
menu, etcj 
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User Objects In Memory 



• User objects are stored in the session pool, the 
desktop heap or the shared heap 

• Set in the handle type information table 
(win32k!gahti) 

• The desktop heap and shared heap are read- 
only mapped into user address space 

• Used to avoid kernel transitions 

• Objects associated with a particular desktop 
are stored on the desktop heap 

• Remaining objects are stored in the shared 
heap or the session pool 
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Handle Table & Objects In Memory 



User 



Kernel 



Application [ Read-only 

mapped memory 

Desl<top Heap 



Shared Section 

User Handle 
Table 



Shared Heap 






Desktop Heap 

Object Object 



Shared Section 
User Handle Table 



Shared Heap 



Object Object 



Session 
Pool 

^ Object ~j 
Object 
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Shared Section User Mapping 



• The shared section is mapped into a GUI process 
upon initializing the client Win32 subsystem 

• Essentially means loading user32.dll 

• Mapping itself is performed by CSRSS in calling 
NtUserProcessConnect (InitlVlapSharedSection) 

• The user handle table, at the base of the shared 
section, can be obtained in at least two ways 

• From user32!gSharedlnfo (exported on Windows 7) 

• From the connection information buffer returned by 
CsrClientConnectToServer upon specifying 
USERSRV_SEVERDLL_INDEX (3) 
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Handle Table From User-Mode 



C:\WINDOWS\system32V:md.e» - shdredinfo.exe 



Index Handle Object 




Id 



[0000] 


10000 


0 


0 


0 


<Free> 


[0001 ] 


10001 


bc5dlb48 


0 


c 


<Monitor> 


[0002 ] 


10002 


elal2G98 


elal3008 


1 


<UindDU> 


[0003 ] 


10003 


el5a91f8 


el5ad650 


3 


<IcDn/CursDr> 


[0004] 


10004 


bceooee8 


elal3008 


1 


<Uindou> 


[OOOG ] 


10005 


el63c670 


el5ad650 


3 


<IcDn/CursDr> 


[oooe ] 


loooe 


bce00818 


elal3008 


1 


<Uindou> 


[0007] 


10007 


el5aee80 


el5ad650 


3 


<IcDn/CursDr> 


[0008 ] 


10008 


be G 009 40 


elal3008 


1 


<Uindou> 


[0009 ] 


10009 


el5aee20 


el5adG50 


3 


<IcDn/CursDr> 


[000a] 


1000a 


bcG00a88 


elal3008 


1 


<Uindou> 


[000b] 


1000b 


el5adb80 


el5adG50 


3 


<IcDn/CursDr> 


[000c ] 


1000c 


bcG20Ge8 


elal3008 


1 


<Uindou> 


[OOOd] 


lOOOd 


el7c2658 


el5adG50 


3 


<Icon/Cursor> 


[OOOe ] 


lOOOe 


bcG20818 


elal3008 


1 


<Uindow> 


[OOOf ] 


lOOOf 


el7clG10 


el5adG50 


3 


<Icon/Cursor> 


[0010] 


10010 


bcG20940 


elal3008 


1 


<Uindow> 


[0011] 


10011 


el7b22a8 


el5adG50 


3 


<Icon/Cursor> 


[0012] 


10012 


bc620a88 


elal3008 


1 


<Uindow> 


[0013] 


10013 


el7d7e20 


el5adG50 


3 


<Icon/Cursor> 


[0014] 


10014 


bc6306e8 


elal3008 


1 


<Uindow> 


[0015] 


10015 


el7d7dc0 


el5adG50 


3 


<Icon/Cursor> 
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Desktop Heap User Mapping 



• For each GUI thread, win32k maps the associated 
desktop heap into the user-mode process 

• Performed by win32k!MapDesktop 

• Information on the desktop heap is stored in the 
desktop information structure 

• Holds the kernel address of the desktop heap 

• Accessible from user-mode 

• NtCurrentTeb()->Win32Clientlnfo.pDesklnfo 

• kd>dtwin32k!tagDESKTOPINFO 

• +0x000 pvDesktopBase : Ptr32 Void 

• +0x004 pvDestkopLimit : Ptr32 Void 
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Kernel-Mode -> User-Mode Address 



User-space address of desktop heap objects are 
computed using ulClientDelta 

• NtCurrentTeb()->Win32Clientlnfo.ulClientDelta 

User-space address of shared heap objects are 
computed using ulSharedDelta 

• Defined in win32k!tagSHAREDINFO 



UlClientDelta 



Desktop Heap 



Window 



Cursor 



User 



Desktop Heap 



Window 



Cursor 



Kernel 
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User Object From User-Mode 



C:\WINDQWStav5teni32tamd.eM 



C:\DdI 



HEAD structure 



i\uinware\Desktop>s]iaredinf o .exe 20096 a4 



[»] DumpjjTWibJect data for handle: 2009G 

0000h: | 00020096 00000001 1 elB3f 720 818d6238 
0010h:' bbeUcUlU mmmm* 80000300 c 00008 00 

002 0h: 54009945 00000000 00000000 00000000 
003 0h: 00000000 bbe8c768 00000000 00000000 
0040h: 00000000 00000004 0000017c 00000026 

005 eh :-BBBBBBBa, 00000004 0000017c 00000026 
0060h: | 773e208bl bbe88328 00000000 bbe8c700 

0070h: UUUUUUUU 00000000 00000000 00000000 
008 0h: 0ag »^ a00 0 0000000 00000000 00000004 
^^00000000 00000000 0009 C 5 08 

Window procedure I 

L. I.IJULU IIIBII U. a i Hf Settings\uinware\Desktop> 



E..T.. 

h. 



.8b.. 
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User Object Types 



• On Windows 1, there are 21 different user 
object types (22 including the 'free' type) 

• Includes 'touch' and 'gesture' objects 

• Information on each type is stored in the 
handle type information table 

• win32k!ghti (undocumented structure) 

• Defines the destroy routines for each type 

• Defines target memory location (desktop/shared 
heap, session pool) 
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User Object Types #1 



ID 


TYPE 


OWNER 


MEMORY 


0 


Free 






1 


Window 


Thread 


Desktop Heap / 
Session Pool * 


2 


Menu 


Process 


Desktop Heap 


3 


Cursor 


Process 


Session Pool 


4 


SetWindowPos 


Thread 


Session Pool 


5 


Hook 


Thread 


Desktop Heap 


6 


Clipboard Data 




Session Pool 


7 


CallProcData 


Process 


Desktop Heap 


8 


Accelerator 


Process 


Session Pool 


9 


DDE Access 


Thread 


Session Pool 


10 


DDE Conversation 


Thread 


Session Pool 



* stored on the desktop heap if the window is associated with a desktop 
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User Object Types #2 



ID 


TYPE 


OWNER 


MEMORY 


11 


DDE Transaction 


Tliread 


Session Pool 


12 


IMonitor 




Shared Heap 


13 


Keyboard Layout 




Session Pool 


14 


Keyboard File 




Session Pool 


15 


Event Hook 


Tliread 


Session Pool 


16 


Timer 




Session Pool 


17 


Input Context 


Tliread 


Desktop Heap 


18 


Hid Data 


Thread 


Session Pool 


19 


Device Info 




Session Pool 


20 (Win 7) 


Touch 


Thread 


Session Pool 


21 (Win 7) 


Gesture 


Thread 


Session Pool 
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User Critical Section 



• Unlike NT, the Window Manager does not 
exclusively lock each user object 

• Implements a global lock per session 

• Each kernel routine that operates on win32k 
structures or objects must first acquire a lock 
on win32k!gpresUser 

• Exclusive lock used if write operations are involved 

• Otherwise, shared lock is used 

• Clearly not designed to be multithreaded 

• E.g. two separate applications in the same session 
cannot process their message queues simultaneously 
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Shared and Exclusive Locks 



; flttributes: bp-based frane 

; stdcall NtUserCheckDesktopByThi-eadldCx) 

NtUserCheckDesktopByThi-eadldeii proc near 



yai-_4= dword ptr -4 
ai'g_0= duoi-d ptr 8 




mou edi, edi 

push ebp 

mou ebp, esp 

push ecx 

push esi 

call _EnterSharedCrit@0 ; EnterSharedCrit( ) 

mou es±, eax 

call ds: inp PsGetCurrentProcesseo ; PsGetCurrentProc 

push eax 

call _IsProcessDwPil@4 ; IsPi'ocessDwm(x) 

test eax, eax 

jnz short loc_BF8i|'i222 



; Attributes: bp-based frane 

; int stdcall NtUserSwitchDesktop(HANDLE Handle, int) 

NtUserSwitchDesktopdS proc near 



uar_18= byte ptr -18h 
uar_ii= duord ptr -4 
Handle= duord ptr 8 
arg_4= duord ptr 8Ch 



nou 

push 

nou 

sub 

push 

call 

nou 

xor 

test 

U 



edi 



edi 
ebp 
ebp 

esp 
esi 

eax 
esi 
duo 

short loc BF8198 



esp 



erEnterUserCritSec(38 ; UserEnterUserCritSecO 
, gptiCurrent 
, esi 

rd ptr [eax+8 



Acquire exclusive lock 
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User-Mode Callbacks 

Kernel to User Interaction 



User-Mode Callbacks 



• In interacting with user-mode data, win32l< is 
required to mal<e calls back into user-mode 

• Lead to the concept of user-mode callbacks 

• Implemented in ntlKeUserModeCallback 

• Works like a reverse system call 

• Previously researched by IvanlefOu and mxatone, 
among others 

• Used extensively in user object handling 

• Some user objects store data in user-mode 
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KeUserModeCallback 



• NTSTATUS KeUserModeCallback ( 

IN ULONG ApiNumber, 
IN PVOID InputBuffer, 
IN ULONG InputLength, 
OUT PVOID * OutputBuffer, 
IN PULONG OutputLength ); 

• ApiNumber is an index into the user-mode callback 
function table 

• Copied to the Process Environment Blocl< (PEB) during the 
initialization of USER32.dll in a given process 

• kd> dt nt!_PEB KernelCallbackTable 

• +0x02c KernelCallbackTable : Ptr32 Void 
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KeUserModeCallback Internals 



• In a system call, a trap frame is stored on the 
kernel thread stack by KiSystemService or 
KiFastCallEntry 

• Used to save thread context and restore registers 
upon returning to user-mode 

• KeUserModeCallback creates a new trap frame 
(KTRAP_FRAME) before invoking KiServiceExit 

• Sets EIP to ntdll!KiUserCallbacl<Dispatcher 

• Replaces TrapFrame pointer of the current thread 

• Input buffer is copied to the user-mode stack 
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KeUserModeCallback 



Create new TRAP_FRAME and set 
EIP to KiUserCallbackDispatcher 



Restore original 
TRAP FRAME 



KeUserModeCallback 



kernel 




NTOSKRNL 



NtCallbackReturn 



Switch to kernel 
callback stack 



Restore original 
kernel stack 



user 



KiUserCallbackDispatcher 



NtCallbackReturn 



NTDLL 



"A 



KernelCallbackTable 



kd> dps poi (7f fda000+2c) 169 

75ccf620 75cb6443 user32 ! fnCOPYDATA 

75cf f 0e4 user32 ! f nCOPYGLOBALDATA 

75cc736b user32 ! fnDWORD 

75cbd603 user32 ! fnNCDESTROY 

75ce50f 9 user32 ! f nDWORDOPTINLPMSG 

75cfflbe user32! fnlNOUTDRAG 

75ce6cd0 user32 ! f nGETTEXTLENGTHS 

75cff412 user32! f nINCNTOUTSTRING 



75ccf 624 
75ccf 628 
75ccf 62c 
75ccf 630 
75ccf 634 
75ccf 638 
75ccf 63c 




ientLoadLibrary 
ClientEventCallback 



\ 

CallbackFunction 



User application 
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Kernel Callback Stack 



On Vista/Windows 7, the kernel creates a new kernel 
thread stack for use during the user-mode callback 

• Windows XP would simply grow the existing stack 

The new trap frame is stored on the new kernel stack 

Information on the previous kernel stack is stored in a 
KSTACK_AREA structure 

• Stored at the base of every kernel thread stack 



kd> dt nt !_KSTACK_AREA 
+0x000 FnArea 
+0x000 NpxFrame 
+OxleO StackControl 
+Oxlfc CrONpxState 
+0x200 Padding 



_FNSAVE_FORMAT 
_FXSAVE_FORMAT 
_KERNEL_STACK_CONTROL 
Uint4B 
[4] Uint4B 



kd> dt nt 
+0x000 
+0x000 
+0x004 
+0x004 
+0x004 
+0x004 
+0x008 
+ 0x 
+ 0x 
+ 0x 
+ 0x 
+ 0x 



!_KERNEL_STACK_CONTROL -b 
PreviousTrapFrame : Ptr32 
PreviousExceptionList : Ptr32 
StackControlFlags : Uint4B 
PreviousLargeStack : Pos 0, 1 Bit 
PreviousSegmentsPresent : Pos 1, 1 
ExpandCalloutStack : Pos 2, 1 Bit 
Previous 
000 StackBase 
StackLimit 



^it 



004 
008 
00c 



KernelStack 
InitialStack 



010 ActualLimit 



KERNEL_STACK_SEGMENT 
Uint4B 
Uint4B 
Uint4B 
Uint4B 
Uint4B 
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Kernel Callback Stack Layout 



Kernel callback stack 



New stack pointer 
(ESP/RSP) 




KTRAP FRAME 



r 



KSTACK AREA 



Information on previous 
trap frame and kernel stack 
(address, etc.) 



Trap frame with EIP = 
ntdlMKiUserCallbackDispatcher 



J 



Kernel stack base 
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NtCallbackReturn 



• NTSTATUS NtCallbackReturn ( 

IN PVOID Result OPTIONAL, 
IN ULONG ResultLength, 
IN NTSTATUS Status ); 

• Used to resume execution in the kernel after a 
user-mode callback 

• Copies the result of the callback back to the 
original kernel stack 

• Restores original trap frame and kernel stack by 
using the information held in the KSTACK_AREA 

• Deletes the kernel callback stack upon completion 
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Applications of User-Mode Callbacks 



• User-mode callbacks allow win32k to perform a 
variety of tasks 

• Invoke application-specific windows hooks 

• Provide event notification 

• Copy data to and from user-mode (e.g. for DDE) 

• Hooks allow users to execute code in response 
to certain actions performed by win32k 

• Calling a window procedure 

• Creating or destroying 

• Processing keyboard or mouse input 
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Windows Hooks 



• Set using the SetWindowsHook APIs 

• Invoked by the kernel through calls to xxxCallHook 

• Typically used to monitor certain system events 
and their associated paramters 

• May alter function parameters depending on 
the type of hook 

• E.g. change the z-ordering of a window in a create 
window hook 

• Processed synchronously 

• The user-mode hook is called immediately at the time 
when the appropriate conditions are met 
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CreateWindow CBT Hook Example 



User 



Application calls 
CreateWindowEx 



User-defined CBT 
Hook Function 



Handle returned to 
application 



Kernel 




r 



1 



^ Assigns class to ^ 

window object ' 



Invoke CBT hook (if set) 4- 



. __ Sends WM_CREATE 
message 



Sends 
WM_NCCREATE 
message 
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Event Hooks 



• Set using the SetWinEventHook APIs 

• Invoked by the kernel through calls to 
xxxWindowEvent 

• Used to notify a user-mode process that a 
certain event occured or is about to occur 

• E.g. inform that a new window has been created 

• Can be processed both synchronously and 
asynchronously (deferred events) 

• In the latter case, the kernel calls 
xxxFlushDeferredWindowEvents to flush the event 
queue 
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Kernel Attacks through User-Mode 

Callbacks 

Vulnerabilities in Win32k 
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User Critical Section vs. Callbacl<s 



• Whenever a callback is executed, the kernel 
leaves the win32k user critical section 

• Allows win32k to perform other tasks while user- 
mode code is being executed 

• Upon returning from a callback, win32k must 
ensure that referenced objects are still in the 
expected state 

• E.g. a callback could call SetParent() to update the 
parent of a window 

• Insufficient checks may lead to vulnerabilities 
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Function Name Decoration 



• Win32k.sys uses function name decoration to l<eep 
tracl< of functions that leave the critical section 

• Prefixed "xxx" and "zzz" 

• Functions prefixed ''xxx'' may leave the critical 
section and invoke a user-mode callback 

• May sometimes require a specific argument or set of 
arguments to trigger the actual callback 

• Functions prefixed "zzz" typically invoke a deferred 
event callback 

• However, if win32k!gdwDeferWinEvent is null, an 
immediate callback is performed 
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Function Name Decoration Issues 



• Functions that leave the critical section and invoke 
user-mode callbacks are not always prefixed 

• Could lead to invalid assumptions by the programmer 

• Easy to spot using IDAPython and cross referencing 

• Lack of consistency in behavior of "zzz" functions 

• Some "zzz" functions seem to increment 
gdwDeferWinEvent while others do not 



Windows 7 RTM 


Windows 7 (MSll-034) 


MNRecalcTabStrings 


xxxMNRecalcTabStrings 


FreeDDEHandle 


xxxFreeDDEHandle 


ClientFreeDDEHandle 


xxxClientFreeDDEHandle 
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Locating Undecorated Functions 



Ef IDA - I:\research\Jkemer\win7_rtm\win32k.idb {win32k.sysjj 



File Edit Jump Search View Debugger Options Windows Help 



01 



IDA View-A 



□ 



structures 



g I m 



Impofts 



o I m 



Exports 



MNRecalcTabStrings(x ,x 
MNRecalcTabStrings(x ,x 
MNRecalcTabStrings(x,x 
MNRecalcTabStrings(x,x 
MNRecalcTabStrings(x ,x 
MNRecalcTabStrings(x ,x 
MNR9calcTabStrings(x ,x 
MNRecalcTabStrings(x,x 
MNRecalcTabStrings(x,x 
MNRecalcTabStrings(x ,x 
MNRecalcTabStrings(x ,x 
MNRecalcTabStrings(x,x 
MNRecalcT^HJJll^i^rYn^/^Jt-x 

00134ASD 



arg_1 0 
arg_1U 



diford ptr 
diford ptr 



18h 
1Ch 



mou 
push 



edi , 
ebp 



Undecorated functions that 
potentially may invoke 
callbacks 



PI Output window 


i UWUIlDW : 


_IJEeateT 


FUNCTION: 


PcatME 


FUNCTION: 


•^JueueNc 


FUNCTION: 


NQtifs 


FUNCTION: 


_DEawIcc 


FUNCTION: 


_DEaw3wi 


FUNCTION: 


_DEawCtl 


FUNCTION: 


SawInpL 


FUNCTION: 


_Wiii32k:l 


FUNCTION: 


_Vid.e qPc 


FUNCTION: 


_UaeElni 


FUNCTION: 


_MN;iecal 


FUNCTION: 


_DT_GetE 


FUNCTION: 


^leplyl* 


FUNCTION: 


_ZapActi 


FUNCTION: 


_CancelI 


FUNCTION: 


_DeatEQS 


FUNCTION: 


_3eiidl>Hii 


FUNCTION: 


_UaeEThi 


FUNCTION: 


_ClientI 


FUNCTION: 


_Fi:eeDI}(i 


FUNCTION: 


IJTDrai 


All done. 




Python 


AU: idle 


DDwn 



FUNCTION: 
FUNCTION: 



FUNCTION: 



FUNCTION: 



FUNCTION: 



FUNCTION: 




±mp EEUaexMpdeCallbackdZO 



,x ,x ,x ,x) 
,x ,x ,x ,x) 
,x ,x ,x ,x) 
,x ,x ,x ,x) 
,x ,x ,x ,x)+2 
,x ,x ,x ,x)+3 
,x ,x ,x ,x)+5 
,x ,x ,x ,x)+8 
,x ,x ,x ,x)+B 
,x ,x ,x ,x)+E 
,x ,x ,x ,x)+12 
,x ,x ,x ,x)+15 

PcatHeaaageZxtende' 

_^^eueNc t i f yHe a a a ge @ 2 0 

Ncti^vOverlavWindCWaS _> ^^^l^^^^^U -> _iir5^_KaUaerMccleUall£.acJ:(d:^U 

^ iidMeaaageCallback@32 -> _3f nlNUIVICZCHaNGZeSZ 

_DEawICCnCallEack@l€ -> _XJ}N-DSVICZCHftNGZ@32 -> iir5>_KeUaeEMD-deCallbackll20 

DrawSwi tchrlndHili t e(|20 —> "idMeaaageCallbackeSi -> _3fiiINDEVICECHfiNGE@32 -> ±mp KeUaeEMcdeCallback@2Q 

— KK3endMeaaageCallback@32 -> _3 f nINDE VICECHftNGE @ 3 2 -> iE5}_KeUaeEMcde Callbacks 20 

_DrawCtlIhUirib@4 -> _XXXGetCerrfindowPEDC@lC -> _3fnINDEVICECHfiNGE@32 -> ±inp KeUaeEMQdeCallback@20 

Ra.WlnpUtTh.Ee a d@ 4 -> XXXrl^^^ _3fEiINDEVICECHfiNGE@32 -> ±mp KeUaerMQdeCallbac:k@20 

. o^x, -p. yj ■- f-.y. ~ ^@32 -> Imp KeUaei:MQdeCallback@20 

_Wxn3i£.kFnpNctX_y@4 -> _-3t^ft^^tchMeaaage@4 -> _3fEiINDEVICECHfiNGE@32 -> ±mp KeUaeEMGdeCallback@20 

VidecPCEtCallcUtIh.Eead@4 -KitJt^iapatchMeaaage(14 -> _3 f nlNDE VICECHfiNGE d 3 2 -> imp KeUaeEMcdeCallbacklg20 

jj -J. . ... . ran— -b- E 3 ya t emCuE a □ E a FEomRegi a t Ey@ 4 -> _xjoEClieEitLcadIinage@2S -> ±mp KeUaeEMcdeCallbackig: 

_UaeEinitia±lZeSaU _XJtXb l KeUaeEMDdeCallback@20 

_MNRecalcIabStEing"a(|24 -> _tf@15 -> iir5}_KeUaeEMQdeCallback@20 

DT GetZxteCltHinuaPEefixea^ _iir5>_KeUaeEMcdeCallback@20 

— — fyWinZvent@4 -> _xxxClientCallWinEventPEDC@12 -> ±inp KeUaeEMQdeCallback@20 

EleplyHeaaage@4 -> _XJtJtSl6jWinZvent@4 -> _xxjtClientCallWinEventPEQC@12 -> ±inp EeUaeEMQdeCallback@20 

,,tfHcck@15 -> _fnHkINLPM3G@2S -> ±inp KeUaeEMQdeCallback@20 

_jtJtxCl i entCDpylinage @ 2 0 -> iir5J__KeUa e EModeCal lback@ 2 0 

±mp KeUa eEMcdeCallback@20 

Ue a t E c y Pe ndi ngDe a k t cpa @ 8 -eUaeEMDdeCaiiback(i20 

odeCallback@20 
-^HadeCal lback@20 

_UaeEThEeadCallcut@S -> _xj- 
_C1 
_Fe 
DT 



ZapActiveAndFccua@0 -> xi^^ 

rLdcw3inIccn@12 

_CancelInputState@S -> _JOUHj,ead3etup@o 



FUNCTION: _Send:>iJ3nIccnChange@4 



FUNCTION: 
FUNCTION: 
FUNCTION: 
All done _ 




Search for functions that may 
call KeUserModeCallback or 
leave the user critical section 
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Object Locking 



• Objects expected to be valid after the kernel 
leaves the user critical section, must be locked 

• The cLockObj field of the common object header 
stores the object reference count 

• Two forms of locking 

• Thread locking 

• Assignment locking 
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Thread Locking 



* Used to lock objects or buffers within the context 
of a thread 

• ThreadLock* (inlined mostly) and ThreadUnlock* 

* Each thread locked entry is stored as a TL structure 

• kd>dt win32k!_TL 

• +0x000 next : Ptr32 _TL 

• +0x004 pobj :Ptr32Void 

• +0x008 pfnFree : Ptr32 Void 

* Pointer to the thread lock list is stored in the 
THREADINFO structure of a thread object 

* Upon thread termination, the thread lock list is 
processed to release any outstanding entries 

• xxxDestroyThreadlnfo -> DestroyThreadsObjects 
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Thread Locking By Example 



NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 
NtUserDragDetect 



; Attributes: bp-based frane 

; stdcall NtUserDragDetect(x , 

_NtUserDragDetect@12 proc near 

tl= _TL ptr -0Ch 
hund= diford ptr 8 
arg_4= duord ptr OCh 
arg_8= duord ptr 1 Bh 



mou 
push 
mnu 



edi, edi 
ebp 

phn. p*^n 



NtUserDragDetect (X ,x ,x)+1E 
NtUserDragDetect (X ,x ,x)+1E 
NtUserDragDetect (X ,x ,x)+1E 
NtUserDragDetect (x,x,x) +24 
NtUserDragDetect (x,x,x)+2ft 
NtUserDragDetect (x,x,x)+2C 
NtUserDragDetect (x,x,x)+2F 
NtUserDragDetect (x,x,x) +32 
NtUserDraaDetectf x-X-x)+34 

H^M^^I XXX function = 
NtUserl Possible callback 
NtUserDragDetect (X ,x ,x J 
NtUserDragDetect (X ,x ,x) +41 
NtUserDragDetect (X ,x ,x) +46 
NtUserDragDetect (X ,x ,x) +48 



loc_ 
mou 
add 
nou 
nou 
lea 
nou 
mou 
inc 
push 
push 
push 
call 
mou 
call 



■ ptl 



BF95667F: 

ecx, _gptiCurrent 
ecx, tagTHREADINFO 
edx, [ecx] 
[ebp+tl -next] , edx 
edx, [ebp+tl] 
[ecx], edx 
[ebp+tl -pobj ] , eax 
[eax+tagUND .head .cLockObj ] 
[ebp+arg_8] 
[ebp+arg_4] 
eax 

_xxxDragDetect@12 ; xxxDi^ 
esi, eax 

_ThreadUnlock1@8 ; ThreadUnlockl ( ) 



Thread lock entry 
added to TL list 



Object lock count 
incremented 
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Assignment Locking 



• The handle manager provides functions for 
thread independent locl<ing of objects 

• HMAssignmentLock(Address,Object) 

• HMAssignmentUnlock(Address) 

• Assignment locl<ing an object to an address 
with an initialized pointer, releases the existing 
reference 

• Does not provide the safety net thread locking 
does 

• E.g. if a thread termination occurs in a callback, the 
thread cleanup code must release these references 
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Object Locking Vulnerabilities 



• Any object expected to be valid after a user- 
mode callback should be locked 

• Similarly, any object that no longer is used by a 
particular component should be released 

• Mismanagement in the locking and release of 
objects could result in the following 

• No retention: An object could be freed too early 

• No release: An object could never be freed, or the 
reference count (e.g. 32-bit on x86) could wrap 
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Object Use 



User 



Free object 
e.g. DestroyWindowO 



^ 

User-mode ^ 
function 

J 



Free 



Kernel 




User-mode 
callback 



Use after free 



Operate on 
object 
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Window Object Use-After-Free 



• In creating a window, an application can adjust 
its orientation and z-order using a CBT hook 

• Z-order is defined by providing tfie liandle to tfie 
window after which the new window is inserted 

• win32k!xxxCreateWindowEx failed to properly 
lock the provided z-order window 

• Only stored a pointer to the object in a local variable 

• An attacker could destroy the window in a 
subsequent user-mode callback and trigger a 
use-after-free 
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Window Object Use-After-Free 



lea 

mou 

mou 

push 

lea 

push 

push 

push 

call 

test 

jnz 






eax, [ebp+cstruct] 

[ebp+cbt -Ipcs] , eax 

[ebp+cbt -hwndlnsertAf ter] , edi 

5 

eax, [ebp+cbt] 
eax 

duord ptr [ebx] 
HCBT_CREATEWND 
_xxxCallHook@16 
eax, eax 
loc BF89365C 



mou eax, [ebp+cstruct .x] 

mou [ebp+posx], eax 

mou eax, [ebp+cstruct .y] 

mou [ebp+pos_y], eax 

mou eax, [ebp+cstruct -cx] 

mou [ebp+xsize] , eax 

mou eax, [ebp+cstruct .cy] 

mou [ebp+ysize] , eax 

push [ebp+cbt -hwndlnsertAf ter] 

call _PWInsertAfter@4 ; PWInsertAf ter (x) 

mou [ebp+pwndlnsertAf ter] , eax ; uindow object pointer 

jnp short loc_BF892EB1 



Get object pointer from handle 
(cbt.hwndlnsertAfter) 



Operate on freed 
object 



User-nnode callback(s) 




push 
push 
push 
call 
push 
push 
push 
call 
mou 



Destroy Window(hwnd) 



893924: 
esi 

[ebp+pwndlnsertAf ter] 
ebx 

_LinkUindowQ12 ; LinkUindow(x ,x ,x) 

e 

ieh 

esi 

_zzzLockDisplayAreaAndInualidateDCCache(l12 ; zzzLockDisplayAreaAndInualidateDCCache(x ,x ,x) 
eax, [ebp+wndParent] 
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Keyboard Layout Object Use-After-Free 



• In loading a keyboard layout, 
win32k!xxxLoadKeyboardLayoutEx did not lock 
the keyboard layout object 

• Pointer stored in local variable 

• An attacker could unload the keyboard layout 
in a user-mode callback and thus free the 
object 

• Subsequently, upon using the object pointer 
the kernel would operate on freed memory 
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Keyboard Layout Object Use-After-Free 



Ld 1^ 

push [ebp+hkl] 

push 9di 

call _HKLtoPKL08 

mou ebx, eax 

mou [ebp+pkl], ebx 

test ebx, ebx 

jnz short loc_BF8150E5 



get keyboard layout objecct 
store pointer (not locked) 




Get object pointer 
from handle (hkl) 



UnloadKeyboardLayout (hkl) 



U 



loc_BF8153F9: 

mou edi, [ebp+ptiCurrent] 
mou ebx, [ebp+pkl] 



Operate on freed 
object 



M ^ 



Pointer to freed 
memory 



lou eax, [edi+tagTHREftDINFO.ptl] 

lou [ebp+tl -next] , eax ^ 

ea eax, [ebp+tl] 

ush ebx 

mou [edi+tagTHREftDINFO.ptl], eax 

inc [ebx+tagKL .head .cLockObj ] ; Freed memory 

push esi 

mou [ebp+tl .pobj ] , ebx 

call _xxxSetPKLinThreads@8 ; xxxSetPKLinThreads(x ,x) 

push 8eeeeeeeh 

push ebx 

push [ebp+puinsta] 

call _xxxInternalUnloadKeyboardLayout(l12 ; xxxInternalUnloadKeyboardLayout(x ,x ,x) 

call ThreadUnlockieo ; ThreadUnlockl ( ) 
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Object State Validation 



• Objects assumed to be in a certain state should 
always have their state validated 

• Usually involves checking for initialized pointers or 
flags 

• User-mode callbacks could alter the state and 
update properties of objects 

• A drop down menu is no longer active 

• The parent of a window has changed 

• The partner in a DDE conversation terminated 
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DDE Conversation State Vulnerabilities 



• Dynamic Data Exchange (DDE) 

• Legacy protocol using messages and shared memory to 
exchange data between applications 

• Several functions did not sufficiently validate DDE 
conversation objects after user-mode callbacks 

• Used to copy data in and out from user-mode 

• An attacker could terminate a conversation in a 
user-mode callback and thus unlock the partner 
conversation object 

• Could result in a NULL pointer dereference as the function 
did not revalidate the conversation object pointer 



NORMAN 



DDE Conversation Message Handling 



Conversation 
Object 
(Client) 



r 



Conversation 
Object 
(Server) 



PostMessage / 
GetMessage 



Message Transnnit 



Kernel 



DDE 
Handling 



i 



r 



Client 
Window 



Data Copy 



PostMessage / 
GetMessage 




T H User-mode 
callback 



Data Copy 



User-mode 
callback 



Server 
Window 
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DDE Conversation Object NULL Dereference 



loc_ 
mou 
lea 
push 
lea 
push 
lea 
push 
push 
call 
mou 



BF8FB899: 
edi , 



[ebp+arg_4] 
[ebp+P] 



eax 
eax 

eax, [ebp+arg_4] 
eax 

eax, [ebp+uar_4] ^ 
eax 

duord ptr [edi] 

_xxxCopyDdeIn@16 ; xxxCopyDdeIn(x ,x ,x ,x) 
ebx, eax 
ebx, 2 

short loc BF8FB8FC 



Terminate the conversation 
in a user-nnode callback 



User-mode callback(s) 



Copy data to be sent in from 
user-mode 



K-H if} 



push 
mou 
push 
or 

push 

push 

push 

push 

call 

mou 

test 

U 



int 



Possible NULL pointer 
dereference 



[ebp+uar_4] 
eax, [ebp+arg_8] 
[ebp+P] ; P 

duord ptr [eax], BOeeeeeOh 
e ; int 

[ebp+arg_4] ; int 

oFFset _xxxExecuteAck@12 ; int 
duord ptr [esi+10h] ; conuersation object pointer 
_flnticipatePost@24 ; AnticipatePost(x ,x ,x ,x ,x ,x) 
[edi], eax 
eax, eax 

short loc BF8FB8F9 
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Buffer Reallocation 



• Many user objects have item arrays or other 
forms of buffers associated with them 

• E.g. menu items array 

• Item arrays where elements are added or 
removed are often resized to conserve memory 

• Buffer freed if the array is empty 

• Buffer reallocated if elements is above or below a 
certain threshold 

• Any buffer that can be reallocated or freed 
during a callback must be checked upon return 

• Failure to do so could result in use-after-free 
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Buffer Reallocation 



1 

Get number 




of items in 




array (k) 




1 


1 

i 


1 

Get pointer 




to array 





Kernel 



Should revalidate 
buffer pointer 



Item = 
array[n] 

I — I 



Operate on item 
(user-mode 
callback) 



x 



Should revalidate 
number of items 
(k) 



if (+ + n < 
k) 



User 



Resize or 
delete array 
in callback 
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Menu Item Array Use-After-Frees 



• Menus may hold an arbitrary number of menu 
items 

• stored in a dynamically sized array pointed to by the menu 
object structure (win32k!tagMENU) 

• Win32l< did not revalidate the menu items array 
pointer after user-mode callbacks 

• No way to "lock" a menu item 

• Any 'xxx' function operating on menu items was 
potentially vulnerable 

• An attacker could cause the buffer to be 
reallocated in a callback and trigger a use-after- 
free 
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Menu Item Array Reallocation 



CreatePopupMenuO or 
CreateMenuO 




l^t InsertMenuItem(...) creates 
menu items array of 8 taglTEM 
entries 



9^^ InsertMenuItem(...) expands 
array by 8 items and forces 
reallocation 
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Menu Item Processing Use-After-Free 



h-H el] 




BF89C779 


mou 


eax, [esi+tagMENU -cltens] 




BF89C77C 


mou 


ebx, [esi+tagMENU .rgltens] 




BF89C77F 


mou 


[ebp+cltens] , eax 




BF89C782 


cmp 


eax, edx 




BF89C781I 


■i^ 








Li 




BF89C786 add ebx, taglTEM.spSubMenu 



ui an 


BF89C789 






BF89C789 


loc 


BF89C789: 


BF89C789 


mou 


eax, [ebx] 


BF89C78B 


dec 


[ebp+cltems] 


BF89C78E 


cmp 


eax, edx 


BF89C790 


U 


short loc BF89C7C1I 



^ ^ 



lock submenu 



Li h-H 


BF89C7B2 








BF89C7B2 


loc_ 


BF89C7B2: 




BF89C7B2 


push 


edi 




BF89C7B3 


push 


duord ptr [ebx] 




BF89C7B5 


call 


_xxxSetMenuInFo@8 


; xxxSetMenuInFo(x ,x) 


BF89C7BA 


call 


_ThreadUnlock1@0 ; 


ThreadUnlock1() 


BF89C7BF 


xor 


ecx, ecx 




BF89C7C1 


inc 


ecx 




BF89C7C2 


xor 


edx, edx 





Resize array in 
callback 



4 



User-mode 
callb ack 



citems (array count) 
is not revalidated 



BF89C7C1I 

BF89C7C1I loc 

BF89C7C1I add" 

0F89C7C7 cmp 

BF89C7CA jnz 



rgltems pointer (ebx) is 
not revalidated 



BF89C7C1|V 

ebx, 6Ch 
[ebp+cltems], edx 
short loc BF89C789 
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SetWindowPos Array Use-After-Frees 



• SMWP objects are used to update the position of 
multiple windows at once 

• Created in BeginDeferWindowPos( int dwNum ) 

• Hold a dynamically sized array of multiple window position 
structures 

• In operating on the SMWP array, win32k did not 
revalidate the array pointer after user-mode 
callbacks 

• An attacker could force the array to be reallocated 
by inserting entries using DeferWindowPos(...) and 
trigger a use-after-free 
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SetWindowPos Array Reallocation 



BeginDeferWindowPos( 

4) 




Creates SMWP array of 4 
entries 



DeferWindowPos(...) 

fills SMWP array entries 




DeferWindowPos(...) expands 
array by 4 items and forces 
reallocation 
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SMWP Item Processing Use-After-Free 



▼ 


U 


BF8A37CB 








BF8A37CB 


loc_ 


BF8A37CB 




BF8A37CB 


mou 


edi , 


[ebx] 


BF8A37CD 


test 


edi , 


edi 


BF8A37CF 


U 


loc_ 


BF8A3DD7 



^ ^ 



BF8A37D5 nou dl, 1 

BF8A37D7 mou ecx, edi 

BF8A37D9 call @HMUalidateHandleNoSecure@8 ; HMUalidateHandleNoSecure(x ,x) 

BF8A37DE mou esi, eax 

BF8A37Ee mou [ebp+pund], esi 

BF8A37E3 test esi, esi 

BF8A37E5 jz loc_BF8A3DCD . 



U h-H 


BF8A3839 


push 


ebx 


BF8A383A 


push 


eax 


BF8A383B 


push 


UM_UINDOUPOSCHANGING 


BF8A383D 


push 


esi 


BF8A383E 


call 


_xxxSendMessage@16 ; xxxSendMessage(x ,x ,x ,x) 


BF8A381|3 


mou 


eax, [ebx+U] 


BF8A381|6 


mou 


[ebx], edi 


BF8A381|8 


cmp 


.eax, OFFFFFFFEh 


BF8A381|B 


jnz y 


^ 1 short loc_BF8A3878 


y 1 1 



Resize array in 
callback 



User-mode 
callback 



EBX may point to 
freed memory! 



\^ m 



Get next item in 
array 



BF8A3DD7 

BF8A3DD7 loc_BF8A3DD7 : 

BF8A3DD7 add ebx, 6eh 

BF8A3DDA dec [ebp+count] 

BF8A3DDD jns loc_BF8A37CB 
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Time-of-Check-to-Time-of-Use 



• The user critical section is generally used to 
prevent TOCTTOU issues in user object 
handling 

• User-mode callbacks may allow an attacker to 
manipulate an object or global value before it is used 

• Can be particularly dangerous in clean up 
routines 

• May invoke callbacks after checks have been made 

• Could result in stale references to objects or buffers 

• Values that may have changed must always be 
(re)checked after a callback has taken place 
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Time-of-Check-to-Time-of-Use 



U k4 @ 



; int stdcall xxxCancel 

xxxCancelCoolSuitchdO proc^ 
mou eax, gspundAltTab 
test eax, eax 
jz short locret_BF8E82C, 



1 



Checks pointer to 
alt-tab window 




User-nnode callback 
if event hook is set 



@ y 


mou 


ecx, [eax+8] 1 


cmp 


ecx, ptiCurrent 1 


jnz 


short locret_BF8E82CB| 



Assignment locked 
pointer 



push 
push 
push 
push 
push 
call 
push 
call 
xor 
nou 



Attempts to destroy 
window without 
rechecking object 
pointer 




uent(x ,x ,x ,x ,x) 




OFFFFFFFCh 
eax 

EUENT_SVSTEM_SUITCHEND 
_xxxUindouEuent(12e ; xxxUi 

gspwndflltTab 
_xxxDestroyUindou(lU ; xxxDestroyUindou(x) 
edx, edx 

ecx, ofFset gspwndflltTab 

(IHMflssignmentLockdB ; HMflssignmentLock(x ,x) 



icret_BF8E82CB: 
?tn 

ExxCancelCoolSwitchdQ endp 
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Handle Validation 



• Required to validate handles, their type, and 
retrieve the corresponding object pointers 

• HMValidateHandleO and friends 

• Generic handle validation should be avoided 
unless the structure of the object is irrelevant 

• Only checks handle table entry and ignores type 

• Functions that revalidate handles after 
callbacks, may no longer be operating on the 
same object 

• The uniqueness counter designed to provide handle 
entropy is only 16-bit 
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Insufficient Handle Validation 



iM 


xxxGetMenuBar InFo(x 


,x 


,x,x)+297 


mou 


edi, [ebp+pund] 




xxxGetMenuBar InFo(x 


,x 


,x,x)+29ft 


push 


ecx 




xxxGetMenuBar Inf o(x 


,x 


,x,x)+29B 


push 


ecx 




xxxGetMenuBarInFD(x 


,x 


,x,x)+29C 


push 


1E1h 




xxxGetMenuBar I nFD(x 


,x 


,x,x)+2fl1 


push 


edi 




xxxGetMenuBar I nFD(x 


,x 


,x,x)+2fl2 


call 


_xxxSendMessage@16 


; xxxSendMessage(x ,x ,x ,x) 


xxxGetMenuBar I nFD(x 


,x 


,x,x)+2ft7 


mou 


edx, aheList ; 


handle table pointer 


xxxGetMenuBar I nFo(x 


,x 


,x,x)+2ftD 


mou 


ecx, eax ; 


eax: user handle 


xxxGetMenuBar I nFo(x 


,x 


,x,x)+2ftF 


and 


ecx, OFFFFh 




xxxGetMenuBar I nFo(x 


,x 


,x,x)+2B5 


lea 


ecx, [ecx+ecx*2] 




xxxGetMenuBar I nFo(x 


,x 


,x,x)+2B8 


mou 


ecx, [edx+ecx*4] 




xxxGetMenuBar I nFD(x 


,x 


,x,x)+2BB 


test 


ecx, ecx ; 


ecx: object pointer 


xxxGetMenuBar I nFD(x 




,x,x)+2BD 


U 


loc BF91E1iiB 





Function did not check 
handle type nor validate 
index in handle table 



Function did not check that 
object was an innage 
(icon/cursor) 



U 1-4 fc^I] 



xxxClientLoadImage(x ,x ,x ,x ,x ,x ,x)+16D or 

xxxClientLoadImage(x ,x ,x ,x ,x ,x ,x)+17e mou 

xxxClientLoadImage(x ,x ,x ,x ,x ,x ,x)+172 call 

xxxClientLoadImage(x ,x ,x ,x ,x ,x ,x)+177 mou 



dl, 8FFh ; TVPEGENERIC 

ecx, edi ; handle From user-mode callback 

(IHMUalidateHandleNoRipdS ; HMUalidateHandleNoRip(x ,x) 
edi, eax 
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Exploitability 



Use-After-Frees and NULL Pointer 

Dereferences 
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Vulnerability Primitives 



• Mainly dealing with two vulnerability 
primitives 

• Use-After-Frees 

• Null-Pointer Dereferences 

• Exploitability may depend on the attacker's 
ability to manipulate heap and pool memory 

• Kernel Pool Exploitation on Windows 7 (BH DC '11) 

• Not much public information on the kernel heap 

• Hooking user-mode callbacks is easy 

• NtCurrentPeb()->KernelCallbackTable 
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Kernel Heap 



• The kernel has a stripped down version of the 
user-mode heap allocator 

• ntlRtlAllocateHeap, ntlRtlFreeHeap, etc. 

• Used by the shared and desktop heaps 

• Neither heaps employ any front end allocators 

• ExtendedLookup == NULL 

• No low fragmentation heap or lookaside lists 

• Neither heaps encode or obfuscate heap 
management structures 

• HEAP.EncodeFlagMask==0 
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Desktop Heap Base 



^ Kernel 'com :pipe,resetE=0, reconnect, port =\\.\pipe\kd_Windows_7' - Win'Dbg: 6.12.0002 .633 AMD64 



File Edit View Debug Window Help 

I -El n I f^} {^^ 



Command - Kernel 'com:pip^re£ets=0,reconnec1;port=\\.\pipe\kd_Windows_7' - WinDbg:6.12.0002.633 AMD64 



rivriifi Ci-ttttT,^ f -i T-.-i 1 -i f ttFJj 

0k04c EncodeFlagMask 
OkOBO Encoding 
0x058 Po i n t er Key 
TTKTT^^^nTT: er cep t: o:^ 



HEAP ENTRY 



+0k060 VirtualMemory Threshold : OsfeOO 
+0k0&4 Signature Oseeffeeff 
+0k068 Segment Reserve : OkIOOOOO 
+0k06o Segment Commit : 0k2000 
+0k07G DeCommitFreeBlockThreshold : 0k200 
+0k074 DeCommitTotalFreeThreshold : 0k2000 
+0k078 TotalFreeSize : 0K5a9 
+0k07o MaKimumAllocationSize : 0K7ff^^^ 



EncodingFlagMask 
and PointerKey 



No front end 
allocators 



_HE AP_L I ST_LOOKUP f ea 0 0 1 3 8 



+0k080 ProoessHeapsList IndeK : 0 
+0k082 HeaderValidateLength : 0k138 
+0k084 Header Vali da teCopy : (null) 
+0k088 Next Aval lableTaglndeK : 0 



+ 0 K 0 8 a Max i mumTag I ndes 
+0k08o TagEntries 
+0k090 UCRList 
+0k098 AlignRound 
+0k09o AlignMask 



+0k0 0 0 ExtendedLookup 
+0k004 ArraySize 
+0k008 Extraltem 
+OkOOc ItemCount 
+0x010 OutOf Rangeltems 
+0x014 Easelndex 
+0x018 ListHead 
+0x01c ListsInUseUlong 
+0x020 ListHints 



0 

(null) 
_LIST_EHTr 
Oxf 

Oxf f f f f f f £ 

+0x0a0 VirtualAllocdBlocks : _LIST_EWTKY L UxteaUUUaU - UxteaUUUaU 
+0x0a8 SegmentList : _LIST_EHTRY [ OxfeaOJIdlO - RxfRr^nnni H 1 

+0x0b0 AllocatorBackTracelndex 0 

eflvflhiA Wr-iv. rii=rl i i-^ f i=rl T i f T i=t-. rr f V. ■ ^^^^^^^^^^ ^ 
OxObO Blockslndex : 0xfea00138 Void I 
+ UxUbo UL Kinaex ^ : i^nullj ' 



(null) 

0x80 

1 

Oxlf 

2 
0 

Oxf ea000c4 
Oxf eaOOlBc 
Oxf ea0016c 
J 



LIST_ENTRY [ 
-> 0x2010338 
-> (null) 



0xfeal4008 - 0xfeald980 ] 



l+0x0c4 FreeLists 

^OaOll LuLkVailabl e 

+0x0d0 Commi tRout ine 

+0x0d4 Front EndHeap 

+0x0d8 Front HeapLookCount 

+0x0da Front EndHeapType : 

+OxOdc Counters 



Free list 



_LIST_EHTRY [ 0xfeal4008 - 0xfeald98 0 



0x93bb&9e9 
(null) 
: 0 
0 ' ' 
HEAP COUNTERS 



3 



long win3 2k I UserCommi tDesktopMemory+0 



kd> |dt nt!_HEAP BbOOOof 



Ln 86, Col 



Commit routine to 
extend the heap 



I 



TTmn3C0:0 ASM OVR CAPS NUM 
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Kernel Heap Management 



• Freed memory is indexed into a single free list 

• Ordered by block size 

• ListHints used to optimize list lookup 

• Requested memory is always pulled from the front 
of an oversized heap chunk 

• Remaining fragment is put back into the free list 

• If the heap runs out of committed memory, win32k 
calls the CommitRoutine to extend the heap 

• Attempts to commit memory from the reserved range 

• E.g. win32k reserves OxCOOOOO bytes by default 
(adjustable by user) for desktop heaps 
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Use-After-Free Exploitation 



• Unicode strings can be used to reallocate freed 
memory from within user-mode callbacks 

• Allows control of the contents and size of the heap 
block 

• Caveat: Cannot use WORD NULLs and last two bytes 
must be NULL to terminate the string 

• Desktop heap 

• SetWindowTextW (hWnd^ String) ; 

• Session pool 

• SetClassLongPtr (hWnd, GCLP_MENUNAME, ( 
LONG) String) ; 
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strings As User Objects 



g|j Kernel 'com ;p]pe, resete=^riecMine^poF^^ 



File Edit View Debug Window Help 

I I -li -4 m I {^} {p {Y^ 



Disassembly 



Offset @$ scope ip 



mm 

J[ Previous^ [ Next" 



92da5f 3b 
92da5f 3e 

h2da5f 41 
92da5f 44 
92da5f 47 

h2da5f 4a 
92da5f 4d 

|92da5£50 



894808 
8b4608 
8b4e0c 
89480c 
8b4708 
894608 
897e0c 
8b4708 



92da5f56 897708 

92da5f59 5f 

92da5f5a 5e 

92da5f5b 5b 

92da5f5c c9 

92da5f5d c20800 

92da5f60 90 



mov 
mov 
mov 
mov 
mov 
mov 
mov 
mov 

mov 
pop 
pop 
pop 
leave 
ret 
nop 



dword ptr 
eaK , dword 
ecK , dword 
dword ptr 
eaK , dword 
dword ptr 
dword ptr 
eaK , dword 



[eaK+8 ] , ecK 
ptr [esi+8] 
ptr [esi+OCh] 
[eaK+OCh] , ecK 
ptr [edi+8] 
[esi+8 ] , eaK 
[esi+OCh] ,edi 
tr [edi+8] 



dword ptr [edi+8 ],esi 

edi 

esi 

ebK 



Arbitrary memory 
corruption 

Command - Kernel 'com;pip^resets-0,reconnect,port=\\.\pipe\kd_Windows_7' - WinDbg:6.12,00Ui:.DJj AM1JD4 



m Registers 



kd> g 

Access violation - code cOOOOOOB (Ml second chance Ml) 
¥in32k I KKKSetPKLinThreads+0Ka9 : 

92da5f53 89700c mov dword ptr [eaK+OCh] . esi 

kd> r 

eaK=41414141 ebK=00000000 ecK=ffb222c8 edK=8c436f00 esi=ffblldfO edi=ffa410c8 
eip=92da5f53 esp=968408d4 ebp=9&8408f0 iopl=0 nv up ei pi nz na po cy 

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010203 
win32k I KKKSetPKLinThreads+0Ka9 : 

92da5f53 89700c mov dword ptr [eaK+OCh] . esi ds : 0023 : 4141414d=???????? 

kd> dd edj. 

41414141 41414142 41414141 41414141 
41414141 41414141 41414141 41414141 
41414141 41414141 41414141 41414141 
41414141 41414141 41414141 41414141 
00004141 88853c40 4609000a 6c6d7355 



Customikze... 



f fa410c8 
f fa410d8 
f fa410e8 
f fa410f 8 
f fa41108 
f fa41118 
f fa41128 
f fa41138 



UUUiUUUU uuuuuuuu uuuuuuuu uuuuuuuu 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 



kd> \ 



Unicode string 
allocated in place of 
freed object 



Reg 


Value 






edi 


f fa410c8 




0 


esi 


f fblldf 0 






ebK 


0 






edK 


8c436f 00 






ecK 


f fb222c8 






eaK 


41414141 






ebp 


968408f 0 






eip 


92da5f 53 






OS 8 




ef 1 


10203 






esp 


968408d4 






ss 10 






n 






4 \ rrr 


1 





LnO, ColO SysO;KdSrv:S ProcOOO:0 ThrdOOO;0 ASM OVR CAPS NUM 
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Exploiting Object Locl<ing Behavior 



• Embedded object pointers in the freed object 
may allow an attacker to increment (lock) or 
decrement (unlock) an arbitrary address 

• Common behavior of locking routines 

• Some targets 

• HANDLEENTRY.bType 

• Decrement the type of a window handle table entry (1) 

• Destroy routine for free type (0) is null (mappable by user) 

• KAPC.ApcMode 

• Execute code with kernel-mode privileges by decrementing 
UserMode (1) to KernelMode (0) 
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Exploiting Object Locl<ing Behavior 



Kernel 'com:pipe/esets=0,reconnectjp<irt=\V\pipe\kdJrt/lndows_7' - WlnDbgi^.12.0002.633 AMD64 



I ^ I B 



File Edit View Debug Window Help 

_ \ MX I {F 6^ * I ^ ^^^^^^^ n m I [T\\i\ I 



DiEaEEembly 



Off&et: ^^Sscopeip 



8216c555 90 

win32k!HMUnlockObject : 
8216c556 8bff 
8216c558 55 
8216c559 8bec 
8 2 1 6c 5 5b 8b 4 5 0 3 

8216c561 7506 
8216c563 50 
8216c564 e8cf3a0000 
8216c569 5d 
8216c56a c20400 
|8216c56d 90 



nop 

mov 

push 

mov 



:ine 

push 

call 

pop 

ret 

nop 



Unlocking user-controlled 
pointer (Oxdeadbeef) 



edi , edi 
ebp 

ebp, esp 



win32klHMUnlockObject+OKl3 C3216c569) 
eaK 

win32k I HMUnlockObject Internal (32170033) 

ebp 

4 



Previous 



Next 



Command - KerneF 'com:prp^resets=0/econnect,port=\\Xprpe\kd_Wrndows_7' - WrnDbg:&.12.0Ob2.633 AMD64 



kd> r 

eaK=deadbeeb ebK=f 
eip=8216c55e esp=9 
cs=0008 ss=0010 
win32k!HMUnlockObj 
8216c55e ff4804 
kd> kb 

ChildEBP RetAddr 
9431dca0 8216c9e0 



9431dcb0 
9431dcc3 
9431ddl3 
9431ddl8 



320d0cbl 
320d0bb3 
3235542a 
779464f 4 



002af91c 7795b3f5 
002af95c 7795b3c8 
002af974 00000000 



e95a99 0 ecK=ff 910000 edK=feall4 3 0 esi=feall480 edi=deadbeeb 
4 31dca0 ebp=9 431dca0 iopl=0 nv up ei ng nz na pe nc 

ds=0023 es=0023 fs=0030 gs=0000 efl=00000286 
ect+OsS : 

dec dword ptr [eaK+4] ds : 0023 : deadbeef =???????? 

Args to Child 

deadbeeb 00000000 fe95a973 win32k I HMUnlockObject+OK3 
320d0b3b 0043fa0c 002af35c win3 2k I HMAssignmentLock+0K4 5 
9431dcfc 9431dcf3 9431dcf4 win32k I KKKCsDdeIni t ialize+0K67 
0043fa0c 0043falc 0043fal4 win32k I NtUserDdeIni t ialize+0K23 
0043fa0c 0043falc 0043fal4 nt I KiFastCallEntry+0Kl2a 
7ffdf000 77a4624b 00000000 ntdll I KiFastSystemCallRet 
00fel6e2 7ffdf000 00000000 ntdll !_Rt lUserThreadStart+0K7 0 
00fel6e2 7ffdf000 00000000 ntdll! Et lUserThreadStart+Oslb 



HMAssignmentLock 
unlocks the existing user- 
controlled pointer 



kd> 



LnO, ColO SysO:KdSn/:S ProcOOO;0 Thrd 000:0 ASM OVR CAPS NUM 
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NULL Pointer Vulnerabilities 



• Potentially exploitable on the Windows 
platform 

• Non-privileged users can map the null page, e.g. via 
NtAllocateVirtualMemory or NtMapViewOfFile 

• Many NULL pointer vulnerabilities are 
concerned with window object pointers 

• An attacker could map the null page and set up 
a fake window object 

• E.g. define a server-side window procedure and 
handle messages with kernel level privileges 
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NULL Pointer Object Exploitation 




g] Kernel 'com ;pipe/e5ets=0,recon nee:. port =\\;vpipe\kd_WinXP_SP3_dev - WinDbg:6,12.0002,633 AMD 6^ 



File Edit View Debug Window Help 

I I li m I {^} ^uri H^ai^n^Qnni^i 



- JlQl I 



Disassembly 



Offset: (3'$ scope ip 



Previous 



41414142 ?? 

41414143 ?? 

41414144 ?? 

41414145 ?? 



??? 
??? 
??? 
??? 



Next ] 

I 



Command - Kernef ' com: prp^resets=0, reconnect, port-\\.\pipe\kd_WrnXP_SP3_d'ev' - WmDbgi6.12:,0002.633 AMD64 

kd> r 

eaK=00004688 ebH=00000002 ecK=f06e0688 edK=00000000 esi=00000000 edi=el05d830 

eip=41414141 esp=f0&e0634 ebp=f06e0&70 iopl = 0 nv up ' 

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 ' 
41414141 ?? ??? 
kd> kb 6 

ChildEBP RetAddr Args to Child 

WARNING: Frame IP not in any known module. Following frames 
f06e0630 bf814099 00000000 00000002 00000000 0k41414141 
f06e0670 bf80ecc6 00000000 00000002 00000000 win32k I KxxSendMessageTimeout+OKlSa 
f06e0694 bf8457cl 00000000 00000002 00000000 win32k I KHHSendMessage+Oslb 



Message sent to 
null pointer object 



f06e06d0 bf845ef6 00000000 00000000 el05d830 win32k I KXKD¥_SendDestroyMessages+0K35 
f06e071c bf8e82bf 00000000 bf91e8fa bc&9eee0 win32k I KXKDestroy¥indo¥+0K381 
f06e0724 bf91e8fa bc69eee0 00000000 0000f040 win32k I KHsCancelCoolSwi tch+0K2d 
kd> dd 0 

00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 



00000000 
00000010 
00000020 
00000030 
00000040 
00000050 
00000060 
00000070 



000200ac 00000000 el05d830 

00000000 00040000 00000000 

00000000 00000000 00000000 

00000000 00000000 00000000 

00000000 00000000 00000000 

jnnnnnnn OOOOOOOO 00000000 

[41414141 OOOOOOOO OOOOOOOO 

TUUULUJUU OOOOOOOO OOOOOOOO 



<{ 



Fake null page 
window object 



kd> 



Server-side window 
procedure pointer 



LnO, Col O SysO:KdSrv:S Proc 000:0 Thrd 000:0 ASM OVR CAPS NUM 
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Demo 



• Window Object Use-After-Free (CVE-2011- 
1237) 

• Arbitrary kernel code execution via HANDLEENTRY 
corruption 
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Mitigations 



Protecting Against Privilege Escalation 

Vulnerabilities 
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Mitigating Use-After-Free Exploitation 



• Need to address an attacker's ability to 
reallocate the freed memory before use 

• Some approaches 

• Delayed frees while processing a callback 

• Dedicated free lists for user objects 

• Isolate strings used in reallocating memory 

• Track allocations between ring transitions, e.g. 
pointers on the stack before a callback 

• Generally hard to mitigate without significantly 
impacting performance 
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Mitigating NULL Pointer Exploitation 



• We can address null pointer exploitation by 
denying users the ability to map the null page 

• Some potential ways of addressing null page 
mappings 

• System call hooking 

• Page Table Entry (PTE) modification 

• VAD manipulation 

• System call hooking not supported on x64 

• PTE modification requires page to be mapped 
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VAD Manipulation 



• User mode process space is described using 
Virtual Address Descriptors (VADs) 

• structured in self-balanced AVL trees 

• VADs are always checked before PTEs are 
created 

• E.g. used to implement the NO_ACCESS protection 

• VADs are used to secure memory, e.g. made 
non-deletable 

• PEBsandTEBs 

• KUSER SHARED DATA section 
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VAD Tree 



Process 
Object 
(EPROCESS) 



— ► 



VadRoot 
(MM_AVL_TABLE) 



—■ ► 



VAD: 85a52db0 

77cb0 - 77deb 
EXECUTE_WCOPY 
Mapped 



L Mapped I 



' Control Area 

-■► Flags: Accessed, 
File, Image, ... 



I I File Object 
— ■► Name: 

[...J\ntdll.dll 



VAD: 871fl418 

IfO - 2ef 
READWRITE 
Private 



VAD: 85a52ce8 

30 - 33 
READONLY 
Mapped 



VAD: 85a551a0 

dcO - de2 
EXECUTE_WCOPY 
Mapped 



VAD: 85985008 

7ffb0 - 7ffd2 
READONLY 
Mapped 




VAD: 859f9a28 

77ef0 - 77ef0 
EXECUTE_WCOPY 
Mapped 



VAD: 859850d8 

7ffd6 - 7ffd6 
READWRITE 
Private 
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Restricting Null Page Access 



• We insert a crafted VAD entry to restrict null 
page access 

• Ring3 code cannot modify the VAD entry 

• Avoid deletion using the same method 
employed by PEBs and TEBs 

• Secure address range from 0 up to OxFFFF 

• Set protection to NO_ACCESS 

• Use a special VAD flag to prevent memory 
commits 

• Protection cannot be changed on uncommitted 
memory! 
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VAD Tree /w Crafted Entry 



Crafted NO_ACCESS 
VAD inserted at 
leftmost branch in 
VAD tree 





VAD: 85a52ad8 

10 - If 
READWRITE 
Mapped 



VAD: 876c26c0 

0 - f 
NO_ACCESS 
Private 



VAD: 85985128 

20 - 2f 
READWRITE 
Mapped 
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Manipulated Process VAD Tree 



3|) Kernel 'com :pipe/e5ets=0, reconnect. port =\\.\pipe\kd_Winclow5_7' - WmDbg:i6.12,0002.633 AMD64j 



File Edit View Debug VVindcv Help 



si -s„ I {i} ^> I ^ I E ^ ^ 1^ □ ^ 0 □ B S IPIOISI I 



Command - Kemel 'com:pip^resets=0,reconnec1;port=\\,\pipe\kd_Window£_7' - WinDbg;6,lZ,000Z.633 AMD64 



kd> ! process @$proc 0 

PROCESS 85a61ab3 Sessionid: 1 Cid: Oeec Feb: 7ffd9000 
DirBase: If05b3e0 ObjectTable: 9&2dbSS0 HandleCount : 
Image: ktest.exe 



Pa: 



Crafted NO ACCESS Vad 



kd> r? $tO = 5i( (nt !_EPEOCESS *) 0 )->VadEoot ; I vad poi C@$proc+(i>$ 1 0+8 ) ; 



VAD level 


start 


end 


commit 








859ded48 ( 


4) 


0 


f 


524287 Private 


HO ACCESS 


85a7f0d8 ( 


3) 


10 


If 


0 


Mapped 




READWRITE 


85aee360 ( 


4) 


20 


2f 


0 


Mapped 




READWRITE 


86&007fS ( 


2) 


30 


33 


0 


Mapped 




READONLY 


877f5e30 ( 


3) 


40 


40 


1 


Private 




READWRITE 


859aa0b3 ( 


4) 


50 


b6 


0 


Mapped 




READONLY 


875c0390 ( 


1) 


IbO 


2af 


3 


Private 




READWRITE 


8778cl40 ( 


4) 


400 


40f 


3 


Private 




READWEITE 


8719c0b0 ( 


3) 


430 


52f 


15 


Private 




READWEITE 


85a52eb3 ( 


2) 


1020 


1042 


6 


Mapped 


Ese 


EXECUTE ¥RITECOPY 


859f92f0 ( 


4) 


75f 60 


75fa9 


3 


Mapped 


Exe 


EXECUTE ¥RITECOPY 


859b2978 ( 


3) 


76e80 


76f 53 


2 


Mapped 


Exe 


EXECUTE ¥RITECOPY 


877d66f0 ( 


0) 


77cb0 


7 7 deb 


9 


Mapped 


Exe 


EXECUTE ¥RITECOPY 


8756d630 ( 


2) 


77ef 0 


77ef 0 


0 


Mapped 


Exe 


EXECUTE ¥RITECOPY 


877de053 ( 


3) 


7f &f 0 


7f 7ef 


0 


Mapped 




READONLY 


85a97078 ( 


1) 


7f fbO 


7f fd2 


0 


Mapped 




READONLY 


86681b83 ( 


2) 


7f fd9 


7f fd9 


1 


Private 




READURITE 


86185e23 ( 


3) 


7f fdf 


7f fdf 


1 


Private 




READURITE 


Total VADs 




1 8 average 


level : 


3 maximum depth: 4 





Pagef ile-backed section 
Pagef ile-backed section 
Pagef ile-backed section 

\Uindows\System32\locale . nls 



\Users\vmware\Desktop\ktest . exepWMwareD 
\Uindows\System32\KernelBase . dll 
\Uindows\System32xkernel32 . dll 
\Uindows\System32\ntdll . dll 
\Uindows\System32\apisetschema . dll 
Pagef ile-backed section 
Pagef ile-backed section 



kd> !pte 0 

VA 00000000 
PDE at C0600000 PTE at COOOOOOO 

contains 0000000006E3E867 contains 0000000000000000 
pfn 6e3e DA — UUEV not valid 



kd> 



Invalid memory 



Ln 0, Col 0 Sy s 0 : Kd Srv; S P roc 000 ;0 Th rd 000 :0 ASM 0 VR CAP S N U M 
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Mitigation Results 



Function 


Addr 


Type 


Protection 


Result 


NtAI locate VirtualMemorv 


1 


MEM RESERVE 

1 1 ^ 1 1 1 ^ 1 X V ^ 


READONLY 

1 x^/ \Lmy 1 ll ^ 1 


OxCOOOOOlS 


NtAllocateVirtual Memory 


1 


MEM_COMMIT 


READONLY 


OxCOOOOOlS 


NtMapViewOfSection 


1 


MEM_DOS_LIM* 


READONLY 


OxCOOOOOlS 


NtProtectVirtualMemory 


0 




READWRITE 


0XC000002D 


NtProtectVirtualmemory 


0 




READONLY 


0x00000045 


NtFreeVirtualMemory 


0 


MEM_RELEASE 




0x00000045 



OxCOOOOOlS 


STATUS_CONFLICTING_ADDRESSES 


0XC000002D 


STATU S_N OT_CO M M ITTE D 


0xC0000045 


STATUS_INVALID_PAGE_PROTECTION 



*Allows section mapping on page boundary on xS6 platforms 
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Demo 



• Null page mapping mitigation 
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Conclusion 

Remarks and Conclusion 



Future of the Win32k Subsystem 



• Win32k needs a much more consistent and 
security oriented design 

• It should not be necessary for the kernel to make 
direct calls back into user-mode 

• Reconsider performance benefit of shared user and 
kernel-mode memory mappings 

• The Window Manager should provide mutual 
exclusion on a per-object basis 

• Better suited towards multicore architectures 

• Similar to what is done in GDI and the NT executive 
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Conclusion 



• Legacy components constitute the most 
vulnerable parts of an operating system 

• Security is not usually part of the original design 

• Win32k is built around very old GUI subsystem code 

• Kernel exploitation requires knowledge about 
the kernel address space 

• Limiting access to such information is important 

• Although hard, mitigating Windows kernel 
exploitation is possible 
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Questions ? 



• Email: 

• Blog: 

• Twitter: @l<ernelpool 

• Norman MDT Blog: 



